Looks good to me. Have you gotten it to run with a live device?

Reviewed the RCP-over-TCP support. The shape is good: a RcpTransport marker trait with a blanket impl is the minimal way to make SpinelClient transport-agnostic, open_transport keeps the URL handling in one place, set_nodelay is the right call for small request/response frames, and a failed open isn't cached (*phy stays None on the ?), so a transient TCP connect failure is retried by the next command instead of wedging the process.

Verified, no action needed:

• Dropping #[derive(Debug)] from SpinelClient/SpinelWriter is safe — SpinelPhy doesn't derive Debug and nothing else formats the client.
• Box<dyn RcpTransport> satisfies tokio::io::split: supertrait elaboration gives dyn RcpTransport: AsyncRead + AsyncWrite + Unpin, and tokio implements both traits for Box<T>.
• map_err(std::io::Error::other) flattens the ErrorKind to Other but preserves the message, and the only consumer is radio_error, which stringifies — no user-visible regression.
• The std::sync::Mutex → tokio::sync::Mutex swap on phy is forced (the guard now spans an await) and can't deadlock: phy() is the only place that takes that lock.
• Nothing depended on serial control lines (RTS/DTR), so boxing the transport loses no capability.
• A dropped TCP socket is recoverable the same way a USB yank is — the reader loop hits EOF and exits the process for the supervisor to restart.

CI's prek job runs cargo check --workspace, cargo build and cargo clippy --all-targets --all-features -D warnings -Dclippy::nursery, and it passed — so compilation and lints are covered here. (There's no cargo test hook in the pre-commit config, so tests aren't exercised in CI at all; that's pre-existing, not something this PR introduces.)

Four non-blocking points inline — the first two are the substantive ones. One more that isn't anchorable to a changed line: crates/ziggurat-spinel/src/client.rs:313 and :317 log "Serial port EOF, exiting" and "Serial port read failed ({e}), exiting". Those are now the TCP-disconnect path too, and "serial port" will misdirect anyone debugging a network-attached RCP — worth generalising to something like "RCP link" while this is fresh.

Re-reviewed at 3bf94df. All four points from the earlier review are addressed, and I verified each against the tree rather than taking the replies at face value:

• Unbounded TCP connect under the phy lock — fixed in 41ec5d6 exactly as suggested: CONNECT_TIMEOUT (10 s) wraps TcpStream::connect, and the map_err(...)? + ? pair correctly flattens the Elapsed into an io::Error and then propagates the connect's own error. The bound covers DNS resolution too, since connect takes the &str and resolves inside the timeout. The serial path is left unbounded, which is right — open_native_async is a local open(2).
• socket:// alias — added in 41ec5d6. Worth recording that tube0013's correction to my rationale is the accurate one: zigpy.serial.create_serial_connection in zigpy/zigpy-ziggurat#3 backs SpinelTransport, a separate path that talks Spinel straight to the chip and bypasses this server, so it isn't the same config field as --device and there was no interop break to fix. The alias still earns its one line as a guard against pyserial habit, just not for the reason I gave.
• phy() / field doc and TIMEOUT doc — both generalized in 3bf94df, with the EBUSY rationale broadened to cover a second concurrent connection to the same TCP endpoint, and the Wi-Fi caveat made explicit at all three places a reader might look (TIMEOUT, open_transport, --device help). Declaring the TCP path Ethernet-only is the right call over retuning MAX_CONSECUTIVE_TIMEOUTS blind.

Also re-verified this round:

• No lock-ordering hazard from the std::sync::Mutex → tokio::sync::Mutex swap on phy. The remaining stack sync-mutex takes (main.rs:141, :610, :658) are all single-expression scopes that drop the guard before any .await, and self.phy.lock() appears only inside phy() itself, so the two locks are never held simultaneously and neither is held across an await outside the deliberate open-serialization.
• Reset recovery is transport-agnostic — the MAX_CONSECUTIVE_TIMEOUTS path at client.rs:410 only calls notify_reset on the in-memory protocol state; it never reopens the link, so it behaves identically over TCP.
• A second opinion from another model over the same diff returned no findings.

Two leftovers, both cosmetic and non-blocking — neither is anchorable to a changed line, so they're here rather than inline:

• crates/ziggurat-spinel/src/client.rs:316 and :320 still log "Serial port EOF, exiting" and "Serial port read failed ({e}), exiting". This is the same point I raised last time; it's the one thing that didn't get swept up in the 3bf94df wording pass. These two lines are now the TCP-disconnect path as well, and they're what someone debugging a dropped network link will actually see, so "serial port" will misdirect exactly when it's least helpful. Something like "RCP link" would match the vocabulary the rest of the PR just standardized on.
• crates/ziggurat-server/src/main.rs:55 — /// Map a serial-port open failure to a protocol error. on radio_error. Now stale in the same way: it also carries TCP connect and set_nodelay failures.

Testing caveat: there's no Rust toolchain on this machine, so I read the code rather than building it. Compilation and lints are covered by CI's prek job (cargo check --workspace, cargo build, cargo clippy --all-targets --all-features -D warnings -Dclippy::nursery), which is green at this head. That job runs no cargo test, so the test suite is unexercised in CI — pre-existing, not introduced here. tube0013's live-device testing against zigpy/zigpy-ziggurat#3, with connect-and-control confirmed, covers the path that static review can't.

Approving on the strength of the verified fixes; the two wording nits are free to fold into a follow-up or ignore.